vskfandomcom-20200214-history
Category talk:Tracks
Ideas for a catalog of race tracks As you know these custom race track files are quite small and can be downloaded at any time while connected to a race server as either racer or spectator. I am not a fan of the term track and would prefer to use course or chart or even map however, for the sake of being consistent with the developer's choice of terminology I'll try and stick to the word track at this wiki. # There is data about each track that is static or unchanging. #* This data is primarily influenced by the creator of the track. # There is data about each race hosted on that track - specifically data that is affected by decisions made by the host creating a race server. #* Clearly this data is variable and is primarily influenced by the host. # Finally there is data about each race started and finished on a track served up by a race host. #* Clearly this data is variable and is primarily influenced by the fleet (i.e. several users/skippers who decide to race on that server) If a custom track is edited then we now have two creators and two unique tracks even though one is a derivative of the other. This is where some parallels with w:c:genealogy (a.k.a. Familypedia) might be found. w:c:genealogy is heavily utilizing SMW and SF and one contributor (User:Phlox) is especially knowledgaable in the application of these tools. (see below) Over the coming weeks I plan to study the application of a pair of wiki tools called Semantic Media Wiki (SMW) and Semantic Forms (SF). :In short summary these promise to allow just about any data to be tagged with a property as it is added to a wiki page. Thereafter those properties can be used in powerful database-like queries to do such things as allow categories of races (or boats or skins etc.) to be created on-the-fly. As the volume of data grows and perhaps more importantly, as new users of the wiki come along (each user bringing their own unique perspective) the possibilities for creative (and sometimes complex) applications of this database-like capability emerge. * It's one of those situations where you don't try too hard to imagine (and then painstakingly enumerate and plan for) all the possible queries in advance you simply identify all the possible data that could be tagged (annotate is the SMW term used) and then design your page templates for creating pages to do so. At this stage my greatest concern is how burdensome the data entry process might appear to the would-be contributors. For that reason anybody you can think of who has looked into the internal structure of the custom track file and the race autosave file (both use the .Gbx file name extension) would be a good person to get in touch with. Since files accumulate on your computer as you race online, I imagine/hope it is possible to periodically run a script that extracts a dozen or more pieces of data per file into a plain ASCII text XML or maybe a comma separated variable .csv file. With a little format work and possibly a python bot running at this wiki that data should be easily uploaded to the wiki to automatically populate this growing database of query-ready information. So that's the long term plan. There may be a period of time during which only the static data is entered and maybe this is done manually or maybe not. Let's brainstorm the possible data that could be "annotated" for later query-readiness. Creator decisions * number of spawn points * location (are there just 16 international venues? ... or more?) * total course distance (Nm) * nominal duration * screen shot of map view (800x600 PNG or GIF or JPG format) * number of marks * number of gates * length of first leg * longest leg (questionable value) * shortest leg (questionable value) * max wave height * min wave height (questionable value) * max current (can be done but will need a lot of sampling of course area & it will vary during the time of the course, so you cant do this in one dip into the editor) * min current (questionable value) * obstacles (e.g. small vessels, large vessels, islands, headlands, bridges, harbors, piers, whirlpools, shoals, reef, wind shadows near land, etc.) Maybe a bit complex to explain everything so perhaps just a present/absent status for each type of obstacle with no further detail. * coordinates of each mark (questionable value if screen shot provided) Host decisions This data does not have relevance to a user's decision to use or not use a race track/course/map however it does have relevance to such fleet performance information as the fastest finish time for the track. * tide * time of start * prevailing wind direction * prevailing wind strength * wind variability * hosts who count this track among their favorites (see also skippers who enjoy/don't enjoy ...) Fleet decisions To upload this data has to be one or two clicks and no data entry otherwise user simply won't bother with it. Also since we can easily anticipate identical data from multiple skippers in the same race, some uniqueness signature (typically a checksum on the data) * skippers who enjoy this track (popularity measure) * skippers who do not enjoy this track (un-popularity measure) ;Per race data * time and date of race (GMT) (only useful if all skippers with an auto-save of the same race see exactly the same time-date-stamp within that file) * fastest finish time (Imagine a top 10 fastest finishing time query) * name of winning boat * fastest time to first mark (not sure if this is feasible) * number of starting boats * number of finishing boats Request for your ideas In preparing this first draft I have folded in comments from Camster however if you have more ideas to add then sooner is better than later as far as these things go. Even if your idea may not be feasible it is probably best to have at least a placeholder for whatever piece of data and then decide whether or not to use it later on. Request for programming help If you are a java, perl, C++, python etc. programmer then it would be good to read your ideas on how these .Gbx files might be mined for this data and subsequently packaged for upload to the wiki. najevi 10:36, 3 July 2009 (UTC)